This tutorial will focus on Login with Spring Security. We're going to build on top of the previous Spring MVC example, as that's a necessary part of setting up the web application along with the login mechanism.

When working with Spring Boot, the spring-boot-starter-security starter will automatically include all dependencies, such as spring-security-core, spring-security-web, and spring-security-config among others:

If we don't use Spring Boot, please see the Spring Security with Maven article, which describes how to add all required dependencies. Both standard spring-security-web and spring-security-config will be required.

Let's start by creating a Spring Security configuration class that creates a SecurityFilterChain bean.

By adding @EnableWebSecurity, we get Spring Security and MVC integration support:

In this example, we used in-memory authentication and defined three users.

Next we'll go through the elements we used to create the form login configuration.

Let's start by building our Authentication Manager.

The Authentication Provider is backed by a simple, in-memory implementation, InMemoryUserDetailsManager. This is useful for rapid prototyping when a full persistence mechanism is not yet necessary:

Here we'll configure three users with the username, password, and role hard-coded.

Starting with Spring 5, we also have to define a password encoder. In our example, we'll use the BCryptPasswordEncoder:

Next let's configure the HttpSecurity.

We'll start by doing the necessary configurations to Authorize Requests.

Here we're allowing anonymous access on /login so that users can authenticate. We'll restrict /admin to ADMIN roles and securing everything else:

Note that the order of the antMatchers() elements is significant; the more specific rules need to come first, followed by the more general ones.

Next we'll extend the above configuration for form login and logout:

To use the above-defined Spring Security configuration, we need to attach it to the web application.

We'll use the WebApplicationInitializer, so we don't need to provide any web.xml:

Note that this initializer isn't necessary if we're using a Spring Boot application. For more details on how the security configuration is loaded in Spring Boot, have a look at our article on Spring Boot security auto-configuration.

Let's also have a look at the corresponding XML configuration.

The overall project is using Java configuration, so we need to import the XML configuration file via a Java @Configuration class:

And the Spring Security XML Configuration, webSecurityConfig.xml:

Before the introduction of Spring 4, we used to configure Spring Security in the web.xml; only an additional filter added to the standard Spring MVC web.xml:

The filter – DelegatingFilterProxy – simply delegates to a Spring-managed bean – the FilterChainProxy – which itself is able to benefit from full Spring bean life-cycle management and such.

The login form page is going to be registered with Spring MVC using the straightforward mechanism to map views names to URLs. Furthermore, there is no need for an explicit controller in between:

This, of course, corresponds to the login.jsp:

The Spring Login form has the following relevant artifacts:

We briefly discussed a few configurations of the login mechanism when we introduced the Spring Security Configuration above. Now let's go into some greater detail.

One reason to override most of the defaults in Spring Security is to hide that the application is secured with Spring Security. We also want to minimize the information a potential attacker knows about the application.

Fully configured, the login element looks like this:

Or the corresponding XML configuration:

Next we'll configure a custom login page using the loginPage() method:

Similarly, we can use the XML configuration:

If we don't specify this, Spring Security will generate a very basic Login Form at the /login URL.

The default URL where the Spring Login will POST to trigger the authentication process is /login, which used to be /j_spring_security_check before Spring Security 4.

We can use the loginProcessingUrl method to override this URL:

We can also use the XML configuration:

By overriding this default URL, we're concealing that the application is actually secured with Spring Security. This information should not be available externally.

After successfully logging in, we will be redirected to a page that by default is the root of the web application.

We can override this via the defaultSuccessUrl() method:

Or with XML configuration:

If the always-use-default-target attribute is set to true, then the user is always redirected to this page. If that attribute is set to false, then the user will be redirected to the previous page they wanted to visit before being prompted to authenticate.

Similar to the Login Page, the Login Failure Page is autogenerated by Spring Security at /login?error by default.

To override this, we can use the failureUrl() method:

Or with XML:

In this Spring Login Example, we configured a simple authentication process. We also discussed the Spring Security Login Form, the Security Configuration, and some of the more advanced customizations available.

The implementation of this article can be found in the GitHub project – this is an Eclipse-based project, so it should be easy to import and run as it is.

When the project runs locally, the sample HTML can be accessed at: